Repairing or correcting degraded assay performance in clinical analyzer systems has proven to be more difficult than correcting electrical or mechanical issues. Estimating the expected performance and monitoring the actual performance of clinical laboratory testing and diagnostic systems requires detailed and current information. Design and manufacturing clinical diagnostic systems requires testing and integration of thousands of components and subsystems in a complex software coordinated combination for carrying out accurate assays while maintaining a high throughput. An example is provided by the VITROS 4,3™ and ECi line of clinical Diagnostic Analyzers manufactured by Ortho Clinical Diagnostics (“OCD”) of Raritan, N.J.
A clinical diagnostic analyzer contains extensive software monitoring and controlling its operation. Testing and examining every possible state of the analyzer is often not possible in view of the large number of states possible for the combination of software and hardware over the expected life and use of the analyzer. Testing the software in a clinical diagnostic analyzer is expensive, time consuming and difficult. For instance, if a subsystem in the analyzer fails, it is reduced, which is declared to be inactive, and needs to be restarted and initialized before use. Asynchronous messages, generated, for instance due to an unexpected opening of the cover of the incubation chamber, may require the affected replicates to be treated as potentially tampered with. Further, recovery from error conditions may affect multiple other tests due to exceeded limits, missed steps and many other undetected errors. Errors may also cause additional errors to ripple through multiple other tests. Further, such errors or their effect may not be detected in time by the routine process for controlling and regulating the operation of a clinical diagnostic analyzer because different tests may be affected to different degrees. The alternative often is to discard valuable patient samples in various stages of processing and restart the entire instrument, which results in reduced throughput and efficiency.
One of the goals in designing clinical diagnostic analyzers is to prevent the release of questionable laboratory results in view of the harm that may result to a patient from treatment or lack thereof based on erroneous results. Thus, timely error detection is of considerable importance in clinical diagnostic analyzers. Indeed, it is desirable to go beyond ensuring assay and equipment performance to merely satisfy health and safety guidelines in order to reduce the cost of assays while improving the reliability of assay results. At the same time, it is imperative to not discard valid results based on an over-inclusive criterion.
Laboratories use a wide range of techniques to help prevent incorrect or even potentially incorrect results from being released. These include but are not limited to assay control charts, equipment maintenance processes/logs, periodic analyzer maintenance, comparison to patient normal performance for the particular assay, reviewing changes since last result for a patient, grouping of results to calculate a physiologically stable quantity. All of these approaches are designed to react to a performance issue after results are released. Releasing a result typically means not only providing the result, but also indicating reliability of the result. Many checks are performed as infrequently as once a day and are suitable only for detecting long-term trends or frequent outliers or highly degraded performance. This puts the laboratory and patient at risk due to release of assay data with degraded performance for hours or even days before it is detected using these methods. In a busy lab, this can result in hundreds of patient samples being retested with a heightened risk of other than the desired treatment while laboratory throughput decreases.
Clinical diagnostic analyzers, like other complex systems comprising scheduler like controllers, control sub-systems using message traffic comprising commands, responses and asynchronous messages, interrupts and the like. Typically, the scheduler, usually implemented as a software module, controls the operation of the clinical diagnostic analyzer by allocating resources, scheduling the desired tests and tracking the performance of the various commands. The scheduler issues commands to various subsystems, which send back a response indicating the result of carrying out the command. The subsystems may, in turn, in response to receiving a command from the scheduler, send one or more commands to other software modules and receive messages from them indicating the result of executing the corresponding command.
All Subsystem Commands, Command Responses, and Asynchronous messages may be considered to be a sub-system input/output. The software module, a subsystem manager, writes these messages into Emulator Files. The Emulator Files, while voluminous, may be reviewed in course of trouble-shooting. This task, however, tends to be slow and impractical to flag and prevent questionable results from being released without inordinately delaying the release of results. Notably, clinical diagnostic analyzers typically support testing of STAT samples requiring expedited processing. Some additional strategies to track or estimate the performance of complex systems that are also not suitable for handling clinical diagnostic analyzers are describe next.
U.S. Pat. No. 7,254,601 (the “'601 patent”) discloses a method for managing remotely deployed intelligent equipment, but, does not teach timely prevention of release of questionable laboratory results.
U.S. Pat. No. 6,757,714 (the “'714 patent”) and patents and patent applications related thereto disclose obtaining and communicating an error condition of an apparatus via email to a remote server. A predefined template is used to generate the e-mail message by obtaining and inserting one or more variables into the template. The error condition may be included as part of a body of the e-mail message or as part of an attachment to the e-mail message. The error condition is reported using a self-describing computer language, such as eXtensible Markup Language (XML). In general, the error condition is determined with the aid of an embedded controller. The remote server passes the error condition to a customer relationship management system. The '714 patent does not address avoiding the release of erroneous results by preventing the machine from releasing questionable results due to unexpected scheduler or software errors.
What is needed is a reduction in the need to exhaustively review and test every possible state of a clinical diagnostic analyzer in order to ensure robust performance. Instead, better error detection strategies are needed to ensure reliability of results released by a laboratory.